home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-netbios-fcp-01.txt < prev    next >
Text File  |  1993-10-20  |  25KB  |  804 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        T J Dimitri
  8. Internet Draft                                                 Microsoft
  9. expires in six months                                       October 1993
  10. <draft-ietf-pppext-netbios-fcp-01.txt>
  11.  
  12.             The PPP NetBIOS Frames Control Protocol (NBFCP)
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is the product of the Point-to-Point Protocol Working
  19.    Group of the Internet Engineering Task Force (IETF).  Comments should
  20.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a
  33.    ``working draft'' or ``work in progress.''
  34.  
  35.    Please check the 1id-abstracts.txt listing contained in the
  36.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  37.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  38.    current status of any Internet Draft.
  39.  
  40. Abstract
  41.  
  42.    The Point-to-Point Protocol (PPP) [1] provides a method for
  43.    transmitting multi-protocol datagrams over point-to-point links.  PPP
  44.    defines an extensible Link Control Protocol, and proposes a family of
  45.    Network Control Protocols for establishing and configuring different
  46.    network-layer protocols.
  47.  
  48.    The NBF protocol was originally called the NetBEUI protocol and
  49.    was used in versions of DOS and OS/2 LAN Manager.  It is now used
  50.    in Microsoft Windows NT and Microsoft Windows for Workgroups.  This
  51.    document defines the Network Control Protocol for establishing and
  52.    configuring the NBF protocol over PPP.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Dimitri                  expires in six months                  [Page i]
  59. DRAFT                            NBFCP                      October 1993
  60.  
  61.  
  62. 1.  Introduction
  63.  
  64.    PPP has three main components:
  65.  
  66.       1. A method for encapsulating multi-protocol datagrams.
  67.  
  68.       2. A Link Control Protocol (LCP) for establishing, configuring,
  69.          and testing the data-link connection.
  70.  
  71.       3. A family of Network Control Protocols for establishing and
  72.          configuring different network-layer protocols.
  73.  
  74.    In order to establish communications over a point-to-point link, each
  75.    end of the PPP link must first send LCP packets to configure and test
  76.    the data link.  After the link has been established and optional
  77.    facilities have been negotiated as needed by the LCP, PPP must send
  78.    NBFCP packets to choose and configure the NBF network-layer protocol.
  79.    Once NBFCP has reached the Opened state, NBF datagrams can be sent
  80.    over the link.
  81.  
  82.    The link will remain configured for communications until explicit LCP
  83.    or NBFCP packets close the link down, or until some external event
  84.    occurs (an inactivity timer expires or network administrator
  85.    intervention).
  86.  
  87.  
  88. 1.1.  Specification of Requirements
  89.  
  90.    In this document, several words are used to signify the requirements
  91.    of the specification.  These words are often capitalized.
  92.  
  93.    MUST      This word, or the adjective "required", means that the
  94.              definition is an absolute requirement of the specification.
  95.  
  96.    MUST NOT  This phrase means that the definition is an absolute
  97.              prohibition of the specification.
  98.  
  99.    SHOULD    This word, or the adjective "recommended", means that there
  100.              may exist valid reasons in particular circumstances to
  101.              ignore this item, but the full implications should be
  102.              understood and carefully weighed before choosing a
  103.              different course.
  104.  
  105.    MAY       This word, or the adjective "optional", means that this
  106.              item is one of an allowed set of alternatives.  An
  107.              implementation which does not include this option MUST be
  108.              prepared to interoperate with another implementation which
  109.              does include the option.
  110.  
  111.  
  112.  
  113. Dimitri                  expires in six months                  [Page 1]
  114. DRAFT                            NBFCP                      October 1993
  115.  
  116.  
  117. 1.2.  Terminology
  118.  
  119.    This document frequently uses the following terms:
  120.  
  121.    peer      The other end of the point-to-point link.
  122.  
  123.    silently discard
  124.              This means the implementation discards the packet without
  125.              further processing.  The implementation SHOULD provide the
  126.              capability of logging the error, including the contents of
  127.              the silently discarded packet, and SHOULD record the event
  128.              in a statistics counter.
  129.  
  130.    end-system A user's machine.  It only sends packets to servers and
  131.              other end-systems.  It doesn't pass any packets through
  132.              itself.
  133.  
  134.    router    Allows packets to pass through, usually from one ethernet
  135.              segment to another.  Sometimes these are called
  136.              "intermediate-systems".
  137.  
  138.    bridge    Allows packets to pass through with the data field
  139.              unmodified.  Usually from one ethernet segment to another
  140.              or from one ethernet segment to a token-ring segment.
  141.  
  142.    gateway   Allows packets to be sent from one network protocol to
  143.              the same or different network protocol.  For example,
  144.              NetBIOS packets from an NBF network to a TCP/IP network
  145.              which has implemented RFC 1001 and RFC 1002.
  146.  
  147.  
  148. 2.  A PPP Network Control Protocol for NBF
  149.  
  150.    The NBF Control Protocol (NBFCP) is responsible for configuring,
  151.    enabling, and disabling the NBF protocol modules on both ends of the
  152.    point-to-point link.  NBFCP uses the same packet exchange mechanism
  153.    as the Link Control Protocol.  NBFCP packets may not be exchanged
  154.    until PPP has reached the Network-Layer Protocol phase.  NBFCP
  155.    packets received before this phase is reached should be silently
  156.    discarded.
  157.  
  158.    The NBF Control Protocol is exactly the same as the Link Control
  159.    Protocol [1] with the following exceptions:
  160.  
  161.    Frame Modifications
  162.  
  163.       The packet may utilize any modifications to the basic frame format
  164.       which have been negotiated during the Link Establishment phase.
  165.  
  166.  
  167.  
  168. Dimitri                  expires in six months                  [Page 2]
  169. DRAFT                            NBFCP                      October 1993
  170.  
  171.  
  172.    Data Link Layer Protocol Field
  173.  
  174.       Exactly one NBFCP packet is encapsulated in the Information field
  175.       of a PPP Data Link Layer frame where the Protocol field indicates
  176.       type hex 8039 (NBF Control Protocol).
  177.  
  178.    Code field
  179.  
  180.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  181.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  182.       and Code-Reject) are used.  Other Codes should be treated as
  183.       unrecognized and should result in Code-Rejects.
  184.  
  185.    Timeouts
  186.  
  187.       NBFCP packets may not be exchanged until PPP has reached the
  188.       Network-Layer Protocol phase.  An implementation should be
  189.       prepared to wait for Authentication and Link Quality Determination
  190.       to finish before timing out waiting for a Configure-Ack or other
  191.       response.  It is suggested that an implementation give up only
  192.       after user intervention or a configurable amount of time.
  193.  
  194.    Configuration Option Types
  195.  
  196.       NBFCP has a distinct set of Configuration Options.
  197.  
  198.  
  199.  
  200. 2.1.  Sending NBF Datagrams
  201.  
  202.    Before any NBF packets may be communicated, PPP must reach the
  203.    Network-Layer Protocol phase, and the NBF Control Protocol must reach
  204.    the Opened state.
  205.  
  206.    Unlesss otherwise negotiated, exactly one NBF packet is encapsulated
  207.    in the Information field of a PPP Data Link Layer frame where the
  208.    Protocol field indicates type hex 0039 (NBF datagram).
  209.  
  210.    An encapsulated NBF packet for PPP differs from the data field in
  211.    DIX ethernet (RFC 894) because NBF packets do not contain the source,
  212.    destination, or length fields in the datagram packet.  Therefore,
  213.    the encapsulated NBF packet contains two extra octets in the
  214.    beginning of the PPP Information field.  The most significant bit in
  215.    the first octet indicates whether the frame is directed or multicast.
  216.    The next 15 bits indicate the length of the rest of the NBF packet in
  217.    the Information field.
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Dimitri                  expires in six months                  [Page 3]
  224. DRAFT                            NBFCP                      October 1993
  225.  
  226.  
  227.    A summary of the NBF default encapsulation format is shown below.
  228.    The fields are transmitted from left to right.
  229.  
  230.     0                   1                   2                   3
  231.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  232.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  233.    |x|         Length              |    Data ...
  234.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.  
  236.    x
  237.  
  238.       The x field is one bit and indentifies the type of NBF
  239.       packet.  The two values for this field are assigned as follows:
  240.  
  241.       0  NBF directed packet.
  242.       1    NBF multicast packet (IEEE 6 octet addesss 03-00-00-00-00-01).
  243.  
  244.    Length
  245.  
  246.       The Length field is 15 bits and indicates the length of
  247.       the Data field (excluding the two octets in the x and Length
  248.       fields).  The Length field is encoded with the most significant octet first.
  249.       Octets outside the range of the Length field should be treated as
  250.       Data Link Layer padding and should be ignored upon reception.
  251.       When a packet is received with an invalid Length field, the packet
  252.       is silently discarded.
  253.  
  254.    Data
  255.  
  256.       The Data field is zero or more octets as indicated by the Length
  257.       field.
  258.  
  259.  
  260.    The maximum length of an NBF datagram transmitted over a PPP link is
  261.    the same as the maximum length of the Information field of a PPP data
  262.    link layer frame.  Since there is no standard method for fragmenting
  263.    and reassembling NBF datagrams, PPP links supporting NBF MUST allow
  264.    at least 578 (576 + 2 for length and type) octets in the information
  265.    field of a data link layer frame.  It is recommended that an
  266.    implementation allow 1502 (1500 + 2) octets in the information field.
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Dimitri                  expires in six months                  [Page 4]
  279. DRAFT                            NBFCP                      October 1993
  280.  
  281.  
  282. 3.  NBFCP Configuration Options
  283.  
  284.    NBFCP Configuration Options allow modifications to the standard
  285.    characteristics of the network-layer protocol to be negotiated.  If a
  286.    Configuration Option is not included in a Configure-Request packet,
  287.    the default value for that Configuration Option is assumed.
  288.  
  289.    NBFCP uses the same Configuration Option format defined for LCP [1],
  290.    with a separate set of Options.
  291.  
  292.    Up-to-date values of the NBFCP Option Type field are specified in the
  293.    most recent "Assigned Numbers" RFC [2].  Current values are assigned
  294.    as follows:
  295.  
  296.       1       Name-Projection
  297.       2       Peer-Information
  298.       3       Multicast-Filtering
  299.  
  300.  
  301. 3.1.  Name-Projection
  302.  
  303.    Description
  304.  
  305.       This Configuration Option provides a method for the peer to
  306.       provide the other peer of hte NetBIOS names on its network.  The
  307.         sender of the Configure-Request states which NetBIOS names should
  308.         be added by the remote peer.  More than one Name-Projection option
  309.         MAY appear in a single Configure-Request.
  310.  
  311.         Implementations which do not attempt to add any NetBIOS names MUST
  312.       Configure-Reject the Name-Projection Configuration Option.
  313.  
  314.       NetBIOS Gateway implementations which attempt to add NetBIOS
  315.         names MUST respond with Configure-Ack even if no NetBIOS names
  316.       were successfully added.  The Configure-Ack packet MUST contain
  317.       a zero in the Added field if the NetBIOS name was added
  318.       successfully and MUST contain the appropriate non-zero return
  319.       code if the NetBIOS name could not be successfully added.
  320.  
  321.         The implementation may choose to fail configuration if the
  322.         complete list of NetBIOS names is not accepted.  By failing,
  323.       the implementation should terminate NBFCP by sending a
  324.       Terminate-Request packet.
  325.  
  326.       Because adding NetBIOS names can take time and because PPP
  327.       defaults the restart timer to 3 seconds, the restart timer
  328.       SHOULD default to 10 seconds when configuring NetBIOS names.
  329.  
  330.  
  331.  
  332.  
  333. Dimitri                  expires in six months                  [Page 5]
  334. DRAFT                            NBFCP                      October 1993
  335.  
  336.  
  337.    A summary of the Name-Projection Configuration Option format is
  338.    shown below.  The fields are transmitted from left to right.
  339.  
  340.     0                   1                   2                   3
  341.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  342.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  343.    |     Type      |    Length     |      1st NetBIOS-Name
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.    |   1st NetBIOS-Name (cont.)
  346.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  347.    |   1st NetBIOS-Name (cont.)
  348.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  349.    |   1st NetBIOS-Name (cont.)
  350.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  351.    |   1st NetBIOS-Name (cont.)    |    Added      |2nd NetBIOS Name...
  352.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  353.  
  354.  
  355.    Type
  356.  
  357.       1
  358.  
  359.    Length
  360.  
  361.       2 + (Number of NetBIOS names * 17)
  362.  
  363.    NetBIOS-Names
  364.  
  365.       This group of zero or more sixteen octet NetBIOS-Name fields
  366.       contains a list of all the NetBIOS names the peer wishes to add to
  367.       the remote network if the packet is Configure-Request.  If the
  368.       packet is Configure-Reject, the peer does not support this
  369.       configuration option and it can be assumed that no NetBIOS names
  370.       were added.
  371.  
  372.       Because the length field is only one octet only 14 NetBIOS names
  373.       can be added per Configure-Request packet.  If more than 14
  374.       NetBIOS names should be added, more than one Name-Projection
  375.       Request packet will have to be sent.
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Dimitri                  expires in six months                  [Page 6]
  389. DRAFT                            NBFCP                      October 1993
  390.  
  391.  
  392.    Added
  393.  
  394.       This is a one octet field which plays a dual role.  The Added
  395.       field in the Name-Projection Request packet contains the type of
  396.       NetBIOS name added.  A summary of name types is listed below.
  397.  
  398.          01   Unique Name.
  399.          02   Group Name.
  400.  
  401.       If the packet is NOT a Configure-Request the Added field contains
  402.       the NetBIOS return code for the NetBIOS Add Name or NetBIOS Add
  403.       Group Name command as defined in the NetBIOS 3.0 specification
  404.       [3].  A summary of common result codes is listed below in type
  405.       hex.
  406.  
  407.          0D   Duplicate name in local name table.
  408.          0E   Name table full.
  409.          15   Name not found or cannot specify "*" or null.
  410.          16   Name in use on remote NetBIOS.
  411.          19   Name conflict detected.
  412.          30   Name defined by another environment.
  413.          35   Required system resources exhausted.
  414.  
  415. 3.2.  Peer-Information
  416.  
  417.    Description
  418.  
  419.       This Configuration Option provides a way to obtain information
  420.       about the peer providing the one side of the PPP connection.
  421.  
  422.       The nature of this option is advisory only.  It is provided as a
  423.       means of improving an end system's ability to provide information
  424.       from peer to peer about one side of the PPP connection for User
  425.       Interface or Logging purposes.
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. Dimitri                  expires in six months                  [Page 7]
  444. DRAFT                            NBFCP                      October 1993
  445.  
  446.  
  447.    A summary of the Peer-Information Option format is shown below.  The
  448.    fields are transmitted from left to right.
  449.  
  450.     0                   1                   2                   3
  451.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  452.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  453.    |     Type      |    Length     |         Peer-class            |
  454.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  455.    |        Peer-version (major)   |       Peer-version (minor)    |
  456.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  457.    |        Peer-name
  458.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  459.    |        Peer-name (cont.)
  460.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461.    |        Peer-name (cont.)
  462.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  463.    |        Peer-name (cont.)                                      |
  464.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  465.  
  466.  
  467.    Type
  468.  
  469.       2
  470.  
  471.    Length
  472.  
  473.       >=6
  474.  
  475.    Peer-class
  476.  
  477.       The Peer-class field is two octets and indicates the class
  478.       of the communication peer providing the one side of the
  479.       PPP connection. This two octet quantity represents a 16 bit
  480.       unsigned number sent with the most significant octet first.
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498. Dimitri                  expires in six months                  [Page 8]
  499. DRAFT                            NBFCP                      October 1993
  500.  
  501.  
  502.       Initial values are assigned as follows:
  503.  
  504.       Value           Class
  505.  
  506.         1             Microsoft PPP NetBIOS Gateway Dial-In Server.
  507.  
  508.         2             Generic PPP NetBIOS Gateway Dial-In Server.
  509.  
  510.         3             Microsoft PPP Local Access Only Server.
  511.  
  512.         4             Generic PPP Local Access Only Server.
  513.  
  514.         5             Reserved.
  515.  
  516.         6             Generic PPP NBF bridge.
  517.  
  518.         7                 Microsoft PPP Client.
  519.  
  520.         8             Generic PP Client.
  521.  
  522.    Peer-version
  523.  
  524.       The Peer-version field is four octets and indicates the version of
  525.       the communication peer providing one side of the PPP connection.
  526.       The first two octets are the major version number and the last two
  527.       octets are the minor version number.  The major and minor version
  528.       represent a 16 bit unsigned number sent with the most significant
  529.       octet first.
  530.  
  531.    Peer-name
  532.  
  533.       The 16-octet NetBIOS name of the peer.  If the length field
  534.       is 6, no peer name is provided.
  535.  
  536.  
  537. 3.3.  Multicast-Filtering
  538.  
  539.    Description
  540.  
  541.       This Configuration Option provides a way to negotiate the use of
  542.       the Multicast-Forward-Period and the Multicast-Priority.  This
  543.       Configuration Option provides a way to negotiate how to handle
  544.       mulicast packets.  It allows the sender of the Configure-Request
  545.       to state the current handling of multicast packets.  The peer can
  546.       request parameters by NAKing the option, and returning valid
  547.       Multicast-Filtering parameters.
  548.  
  549.       If negotiation about the remote Multicast-Filtering is required,
  550.       and the peer did not provide the option in its Configure-Request,
  551.       the option SHOULD be appended to a Configure-Nak.
  552.  
  553. Dimitri                  expires in six months                  [Page 9]
  554. DRAFT                            NBFCP                      October 1993
  555.  
  556.  
  557.       By default, the peer is pre-configured to an administrator
  558.       assigned Multicast-Forward-Period and Priority.  A
  559.       Multicast-Forward-Period specified as hex type FFFF in a
  560.       Configure-Request shall be interpreted as requesting the remote
  561.       peer to specify a value via Configure-Nak.  A
  562.       Multicast-Forward-Period value specified as hex type FFFF in
  563.       Configure-Nak shall be interpreted as agreement that no value
  564.       exists.  A Multicast-Forward-Period of zero shall indicate that
  565.       all multicast packets SHOULD be forwarded.
  566.  
  567.       An implementation which requires the Requested Multi-Filtering
  568.       option SHOULD fail configuration if the remote peer fails to
  569.       provide the requested value.
  570.  
  571.       Peers that rely on all multicast packets forwarded SHOULD
  572.       request a Multicast-Forward-Period of zero and a
  573.       Multicast-Priority of one by NAKing the Configure-Request
  574.       option and appending the proper parameters to a Configure-Nak.
  575.  
  576.  
  577.    A summary of the Multicast-Filtering Configuration Option format is
  578.    shown below.  The fields are transmitted from left to right.
  579.  
  580.     0                   1                   2                   3
  581.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  582.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  583.    |     Type      |    Length     |    Multicast-Forward-Period   |
  584.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  585.    |   Priority    |
  586.    +-+-+-+-+-+-+-+-+
  587.  
  588.  
  589.    Type
  590.  
  591.       4
  592.  
  593.    Length
  594.  
  595.       6
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608. Dimitri                  expires in six months                 [Page 10]
  609. DRAFT                            NBFCP                      October 1993
  610.  
  611.  
  612.    Multicast-Forward-Period
  613.  
  614.       The Multicast-Forward-Period field is two octets and indicates
  615.       the maximum period in seconds at which multicast packets can
  616.       be sent.  The maximum value for this field is 60 (one minute).
  617.       A value of zero indicates that there is no maximum period at
  618.       which multicast packets can be sent.  A value of hex type FFFF
  619.       indicates that the Multicast-Forward-Period is unknown.  This two
  620.       octet quantity represents a 16 bit unsigned number sent with
  621.       the most significant octet first.
  622.  
  623.  
  624.    Priority
  625.  
  626.       The Priority field is two octets and indicates if multicast
  627.       packets have priority over other packets when being sent.  A value
  628.       of 0 indicates that directed packets have priority.  A value of 1
  629.       indicates that multicast packets have priority.
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Dimitri                  expires in six months                 [Page 11]
  664. DRAFT                            NBFCP                      October 1993
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671. Security Considerations
  672.  
  673.    Security issues are not discussed in this memo.
  674.  
  675.  
  676. References
  677.  
  678.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1331,
  679.          May 1992.
  680.  
  681.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1340,
  682.          July 1992.
  683.  
  684.    [3]   IBM Corp., "IBM Local Area Network Technical Reference",
  685.          Third Edition, November 1988.
  686.  
  687. Acknowledgments
  688.  
  689.    Some of the text in this document is taken from previous documents
  690.    produced by the Point-to-Point Protocol Working Group of the Internet
  691.    Engineering Task Force (IETF).
  692.  
  693.    This document is derivative of drafts written by the following
  694.    people.  Many thanks for their work, and for taking an initial stab
  695.    at the protocol:
  696.  
  697.     TBA.
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718. Dimitri                  expires in six months                 [Page 12]
  719. DRAFT                            NBFCP                      October 1993
  720.  
  721.  
  722. Chair's Address
  723.  
  724.    The working group can be contacted via the current chair:
  725.  
  726.       Fred Baker
  727.       Advanced Computer Communications
  728.       315 Bollay Drive
  729.       Santa Barbara, California, 93111
  730.  
  731.       EMail: fbaker@acc.com
  732.  
  733.  
  734. Author's Address
  735.  
  736.    Questions about this memo can also be directed to:
  737.  
  738.       Thomas J. Dimitri
  739.       Microsoft Corporation
  740.       1 Microsoft Way
  741.       Redmond, WA 98052
  742.  
  743.       EMail: tommyd@microsoft.com
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771. Dimitri                  expires in six months                 [Page 13]
  772. DRAFT                            NBFCP                      October 1993
  773.  
  774.  
  775.                            Table of Contents
  776.  
  777.  
  778.      1.     Introduction ..........................................    1
  779.         1.1       Specification of Requirements ...................    1
  780.         1.2       Terminology .....................................    2
  781.  
  782.      2.     A PPP Network Control Protocol for NBF ................    2
  783.         2.1       Sending NBF Datagrams ...........................    3
  784.  
  785.      3.     NBFCP Configuration Options ...........................    5
  786.         3.1       Name-Projection..................................    5
  787.         3.2       Peer-Information.................................    7
  788.         3.3       Multicast-Filtering..............................    9
  789.  
  790.      SECURITY CONSIDERATIONS ......................................   12
  791.  
  792.      REFERENCES ...................................................   12
  793.  
  794.      ACKNOWLEDGEMENTS .............................................   12
  795.  
  796.      CHAIR'S ADDRESS ..............................................   13
  797.  
  798.      AUTHOR'S ADDRESS .............................................   13
  799.  
  800.  
  801.  
  802.  
  803. 
  804.